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Abstract 


This report summarises user requirements for networking and related 
infrastructure facilities needed to enable effective cooperation 
between US and European research teams participating in the planned 
ESPRIT-DARPA/NSF programme of collaborative research in Information 
Science and Technology. It analyses the problems and disparities of 
the current facilities, and suggests appropriate one and three year 
targets for improvements. It proposes a number of initial actions 
aimed at achieving these targets. Finally, the workshop has 
identified a non-exhaustive set of important issues upon which 
support of future research will depend. These issues could be 
studied in the short term, with the aim of initiating a programme of 
joint research in collaboration technology within the next year. 


SUMMARY OF PRINCIPAL RECOMMENDATIONS AND TARGETS 


EMAIL (6.1) Initiate an intercontinental email operations forum 
involving email service providers in the US and Europe to define and 
implement operational procedures leading to high reliability. The 
forum should be tasked with analysing interoperability problems in 
the existing email systems, and with developing functional and 
performance specifications for email gateways (relays). In addition 
an international email user support group should be organized. The 
target would be to achieve, within one year, routine expectation of 
proper and timely (less than one hour campus to campus) delivery of 
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messages. The three year target would be to provide global directory 
services, a return/receipt facility, and support for privacy and 
authenticity. 


COMPOUND DOCUMENTS (6.2) Hold a workshop to review the ongoing 
compound document research and development programmes in the two 
regions. One aim would be to recommend services, based on 
proprietary compound document email for groups using specific 
conforming products, for deployment within the first year. Another 
would be to propose work items in the NSF/DARPA and ESPRIT programmes 
to ensure a timely collaborative programme could start in mid-1991, 
with a three year target of supporting open system compound document 
email. 


DIRECTORY SERVICES (6.3) Initiate a formal collaboration between 
ongoing US and European efforts to implement and maintain the 
relevant directory databases. Within the first year provide 
effective access to existing directory services, and coverage of 
relevant NSF/DARPA and ESPRIT communities. Within three years 
provide database maintenance tools, knowledge-based navigation 
software, and authentication and capability-based access control 
facilities. 


INTERACTIVE LOGIN (6.4) Identify for which protocol suites 
interactive login will be supported including the provision of 
protocol translation facilities. Within one year identify and 
install the best available interactive software at all interested 
sites. Develop a cooperative effort on authentication and privacy 
support, to provide such facilities within three years, together with 
support for "type of service", and remote X-windows even through 
different protocol suites. 


FILE SERVICES (6.5) Identify and deploy within one year the best 
available products for double-hop (staged) multi-megabyte file 
transfer. Within three years define and obtain or develop multi- 
protocol facilities with automated staging, security and management 
facilities; develop access control models, policies and mechanisms to 
support collaborative file access by ad hoc groups. 


GROUP COMMUNICATIONS SERVICES (6.6) Form a support/working group on 
the use of tools, standards and facilities for group communication 
services; set up a working group to harmonize current development 
activities in group communications with the aim of early deployment; 
hold a workshop to propose a harmonized programme of work in the 
future programmes of ESPRIT and DARPA/NSF. The one year target is to 
provide administrative support for maintaining email mailing lists, 
bulletin boards and shared databases, and to deploy facilities for 
multi-site interactive blackboards. The main three year target is to 
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provide intercontinental services based on mature "advanced 
groupware" facilities. 


VIDEO CONFERENCING (6.7) Within a year install existing technology at 
a limited number of sites in both regions; within three years extend 
these, probably according to international standards, to have enough 
sites to be available without undue travel; organize a workshop on 
packet/ISDN/ATM video conferencing. 


COMPUTER SUPPORTED COLLABORATIVE GROUP WORKING (6.8 and 7) Set up a 
workshop to study the needs of a collaborative effort to provide 
intercontinental packet video, multimedia conferencing and computer 
supported collaborative group technology facilities. The workshop 
should, within a year, propose actions which could be made the basis 
of a future harmonized ESPRIT and DARPA/NSF work program. Within 
three years set up a transatlantic testbed facility to support 
collaborative research programs. 


ACCESS TO UNIQUE RESOURCES (6.9) Organize a workshop dedicated to 
analysing the needs, and defining the steps required, to provide 
pilot access to one or more specific such resources - with due 
attention to networking needs, security provisions, documentation and 
advisory requirements, and usage policies. This is to be done within 
a year - within three years one or more significant transatlantic 
pilots should be set up demonstrating remote secured access. 


DISTRIBUTED VISUALIZATION (6.10) A working group should be set up to 
select which current development efforts in distributed visualization 
to support, identify required standards and begin to distribute 
techniques and software, all within a year. Its year 3 target should 
be to establish mutually agreed upon standards and demonstrate 
transatlantic distributed visualization applications. 


NETWORK MANAGEMENT (6.11) Convene an international research network 
operations, planning and management team to develop and apply 
procedural and technical recommendations for international network 
management; organize a set of international network operations 
centers devoted to configuration management, fault detection, 
isolation and repair of network problems; form one or more 
intercontinental Computer Emergency Response Teams to coordinate 
response to attacks against hosts and networks and to develop 
procedures for collecting actionable evidence. Within one year put 
in place an administrative structure to coordinate existing 
facilities manually and to plan technical solutions; within three 
years technology for automating international network management 
should have been developed and deployed. 
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MULTI-PROTOCOL SUPPORT (6.12) Validate current multi-protocol 
solutions, with a one year target of supporting campus-to-campus 
communication for a subset of coexisting protocol suites (at least 
OSI and TCP/IP), and of deploying internationally supported versions 
of existing application level (protocol-translating) gateways; 
collaborate on research and experimentation with multi-protocol 
routing and resource allocation; make recommendations, to funders and 
national research network service providers, on technical solutions 
and standards for multi-protocol support. Within three years deploy 
improved management and resource allocation facilities for multi- 
protocol routers in order to provide service guarantees. 


CLIENT-SERVER FACILITIES (6.13) Within one year provide limited 
bandwidth intercontinental X-windows, and convene workshops to 
achieve agreements on Remote Procedure Call and Intercontinental 
Distributed File System protocols; form a working group on support 
for X-Windows in OSI and to validate performance through TCP/TPn 
protocol translating gateways; initiate collaboration on 
implementation and test of intercontinental RPC and distributed file 
systems. The main three year target is to achieve support for 
intercontinental RPC and Distributed File Systems. 


ARCHIVAL STORAGE FOR DISTRIBUTED COMPUTING ENVIRONMENTS (6.14) 
Convene an international workshop whose goals are to ascertain the 
relevance to this group of the data storage reference model that is 
nearly ready to be declared an official standard guide; to carry out 
an on-going discussion of the system issues that have to be developed 
as a result of this model; to arrive at solutions to be proposed by 
vendors and users for implementations of Data Systems Storage 
Solutions which are modular, interconnectable, and standard. 


DATA REPRESENTATION AND EXCHANGE (6.15) It is proposed that an 
international working group be established to recommend a standard 
collection of software encompassing a variety of data 
representations. This working group should address the issue of data 
identification embedded in the data stream to allow for later 
extensions. After an initial planning meeting, the group would 
schedule subsequent meetings annually to finalise the current data 
exchange standard recommendation, and to define new work scopes. The 
working group would also make their recommendation known to other 
standards bodies. 


TRANSATLANTIC AND CONTINENTAL DISTRIBUTION FACILITIES (6.16) This 
item is put last only because it is a corollary of the preceding 
recommendations. Use existing joint US/European coordination 
mechanisms (e.g., CCIRN) for planning of higher speed, transatlantic 
links; convene a special CEC/DARPA/NSF task force to consider much 
higher speed transatlantic capacity sharing options; ensure that 
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there is an infrastructure in Europe paralleling the US one of 
providing the majority of relevant campuses access at speeds 
approaching 1.5 Mb/s; encourage European user groups with high data 
transmission requirements to aggregate their data transmission 
facilities; attempt to integrate European application projects (like 
the RACE Applications Pilots) to assist in providing an appropriate 
European distribution network with 10-500 Mb/s access to appropriate 
campuses. The one year targets are to install 2 Mb/s multi-protocol 
distribution facilities in Europe, and 1.5 Mb/s (or higher) 
transatlantic capacity. The three year targets are to install 2 
additional 1.5 Mb/s (or higher) transatlantic links, and to determine 
the feasibility of sharing much higher bandwidth transatlantic links. 


1. INTRODUCTION 


The Networks and Infrastructure Working Group (NIWG) attempted to 
synthesize requirements and identify potential cooperative 
development efforts for network-based capabilities both by internal 
discussion within the working group and through interaction with the 
other working groups in the workshop. 


It is essential for the facilities supporting DARPA/NSF-ESPRIT 
collaboration to be consistent with services being used by the US and 
European projects for their own internal collaboration. We have, 
therefore, had to consider both what facilities must be available in 
the two regions separately and then what must be done to facilitate 
US-European collaboration. 


Between the US and Europe, the Coordinating Committee for 
Intercontinental Research Networks (CCIRN) is addressing the 
improvement of coordination of network services. To support US 
DARPA/NSF and ESPRIT collaboration, it will be necessary to extend 
the use of network services in each region as well as to improve the 
quality of services linking the regions. 


The NIWG met both in Brussels and in Washington. It was led by Ira 
Richer (DARPA) and Rolf Speth (CEC) in Brussels, and Tom Weber (NSF) 
and Rosalie Zobel (CEC) in Washington. The participants were largely 
different in the two meetings, but it was agreed that there would be 
a common set of minutes. It is a commentary on the quality of the 
infrastructure available to some of the participants that nine 
people, from both sides of the Atlantic, contributed to these minutes 
over five days - all by email. The participants are listed in 
Appendix A; a complete set of addresses (including telephone, 
facsimile and email) are given in Appendix B. Because many of the 
abbreviations used here may not be familiar to all the readers, a 
Glossary of Terms is given in Appendix C. 
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SCOPE AND OBJECTIVES 


The scope of the working group was to concentrate on generic, 
network-based user services considered helpful for a wide range of 
collaborative work between US and European groups. We distinguished 
between the capabilities which would benefit from immediate attention 
or were required in the short term (e.g., within a year), and those 
which required longer term development. While the prescribed scope 
was to act only in support of the other groups by making use of 
available technology, we identified one area where we felt more 
research and development was an important adjunct to our scope. 


The working group agreed that the major objectives, based on 
instructions given in the opening plenary sessions, were to identify 
the following: 


(i) user requirements which must be satisfied to support 
cooperative US/European research; 


(ii) technical and other infrastructure requirements which must be 
satisfied to support cooperative US/European research; 


(iii) opportunities and potential means for satisfying these 
requirements; 


(iv) potential obstacles to achieving the desired support; 


(v) mutual benefits which would accrue to the participants in 
recommended cooperative projects; 


(vi) promising collaborative development activities needed for 
a better infrastructure. 


MOTIVATION FOR COLLABORATION ON NETWORKING AND INFRASTRUCTURE 


Computer networking, by its very nature, requires cooperation and 
collaboration among the participants developing, implementing, 
deploying and operating the hardware and software comprising the 
system. The long-term vision is the creation of an infrastructure 
which provides the user (rather than the network) with a distributed 
multi-vendor heterogeneous computing environment - with transatlantic 
facilities approaching those available locally. 


A major element of successful networking is the agreement on 
standards which are to be met by all systems included in the network. 
Beyond technical agreements, there must also be concurrence on 
operational procedures, performance objectives, support for the users 
of the network and ability to plan for enhancement and growth of 
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network services. 


A consequence of these observations is that virtually any effort to 
provide network service support to ESPRIT-DARPA/NSF collaboration 
should be carried out cooperatively between the US and European 
network research, design, development, engineering and operations 
communities. 


4. CURRENT STATE OF NETWORKING IN THE US AND EUROPE 


In the DARPA/NSF communities, there is heavy use of electronic mail 
and computer networking to support a wide range of scientific 
research. There is heavy use of the TCP/IP and DECNET protocols as 
well as special electronic mail protocols in the BITNET and Unix 
users networks (e.g., UUNET). Email use varies in intensity among 
different research disciplines. 


There is an emerging interest in and use of OSI-based protocols, 
particularly for email (X.400) and directory services (X.500). Most 
of the backbone networks making up the Internet use 1.5 Mb/s 
telecommunications facilities although the NSFNET will be installing 
a high speed, 45 Mb/s subnetwork during 1990. There are many Local 
Area Networks (LANs). Plans are in place to support both IP (as in 
TCP/IP) and CLNP (as in OSI) datagram protocols in backbone and 
regional networks. Most of these protocols are already supported on 
LANs. On a selective research basis, a set of 1000 Mb/s research 
testbeds are being installed during 1990-1993. 


In Europe, especially amongst the ESPRIT collaborators, there is more 
limited use of computer networking, with the primary emphasis on the 
use of electronic mail and bulletin boards. There is a strong focus 
on OSI protocols in European wide-area networks, but there is a 
considerably amount of TCP/IP use on LANs, and growing use of TCP/IP 
in Wide Area Networks (WANs) in some countries. Most of the national 
wide-area networks are based on the CCITT X.25 protocols with access 
speeds up to 64 Kb/s, though higher access speeds in the 2 Mb/s range 
are planned for many countries, and just becoming available in some. 
An X.25 international backbone (IXI) has just become operational, 
which connects in the National Research Networks and/or the Public 
Packet Data Networks in each Western Europe country at 64 Kb/s. The 
funding of this network has only been agreed for a further short 
period, and plans to upgrade it to higher speed access are not 
agreed. There are many LANs in place. The OSI connection-oriented 
network service (CONS) is layered above X.25, but there is growing 
interest in supporting the connectionless service (CLNS) concurrently 
with the Internet IP in national and international backbone networks. 
Application testbeds at higher speeds are planned under the CEC RACE 
programme. Many of its higher level user services have not been 
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specified collaboratively - as would be required for wide deployment. 
These points are explained further in Section 6. 


Thus although provisions or plans regarding National networks in some 
CEC member states are not so far behind the American facilities, one 
must note that in effect, because of continental backbone 
limitations, Pan-European facilities are at least a generation 
behind. Specifically, both with respect to existing and planned 
backbone provisions, there is a factor of 25 difference between 
Europe and the USA. In addition, this approximate comparison 
flatters the European scene, since it compares facilities that are 
just coming into existence, and plans that are not yet agreed or 
funded, on the European side with facilities that have been available 
for some time, and plans that will be realised before the end of this 
year, in the USA. 


5. POLLS OF THE OTHER WORKING GROUPS 


The NIWG polled the other seven working groups meeting in Brussels 
and Washington to find out what networking and infrastructure support 
their collaborations might require. In general, a strong emphasis 
was placed on the provision of reliable and timely email, easier 
accessibility of email service, user support and information on 
existence and use of available services. There was serious concern 
about privacy, and great interest in transparency (i.e., hiding the 
details of intercontinental networking). 


Some users mentioned that FAX was easier to use and apparently more 
ubiquitous than email for their communities (there are over 12 M 
facsimile machines installed world-wide). Interest in integrating 
FAX and email was noticeable. Most users recognised the many 
advantages of email for multiple addressees, subsequent reprocessing, 
relaying and cost. 


The requirement for large file transfer was patchy. Many did not 
require such facilities, but several groups required transfer of 100 
MB files and some even 1 GB. Many groups desired remote log-in, but 
found present performance - even on the Internet - inadequate. 
Several wanted global file services and file sharing. 


Many groups wished to use video conferencing - but only if they did 
not have to travel more than two hours to a suitable facility. Some 
groups were interested in computer supported group collaboration - 
but most did not understand this term. 


One group (Vision) desired real time transfer at 300 Mb/s, but most 
had much more modest user-user needs. The needs for less visible 
features like network management, client-user technology, remote 
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visualization standards and data representation and exchange formats 
were not voiced explicitly. However they could be deduced from the 
services which the users did request. 


6. USER SERVICES NEEDED IN THE SHORT AND MEDIUM TERM 


To support collaboration between the research workers, we need a 
number of services between the end users. These require provisions 
which impinge on many management domains: inside individual campuses; 
campus-wide area gateways; national distribution; regional- 
intercontinental gateways; intercontinental distribution. However, 
from the users’ viewpoint, this set of services should constitute a 
system whose internal details are not, or at least should not, be of 


concern. It is the overall performance and reliability exhibited, 
and the facilities made available to the user (and their cost), which 
matter. Inadequacies of bandwidth, protocols, or administrative 


support anywhere in the chain between the end users are, to them, 
inadequacies in the system as a whole. 


To some extent more funding from DARPA/NSF and the CEC can alleviate 
the current difficulties. However it is likely that such funding 
will impact only the international and intercontinental components. 
It is essential that the end-user distribution be strengthened also. 
In the US this requires both Regional and Campus Networks. In 
Europe, it requires activity by the National network authorities 
(usually represented in RARE and/or COSINE), and by the Campus 
network providers. Moreover, not only must the transmission 
facilities be strengthened, but also the appropriate protocol suites 
must be supported; this may require policy decisions as well as 
technical measures. 


We indicate below the services which are required immediately, and 
are visible to the end-users. They often have implications to the 
service providers which have far-reaching consequences. Some of the 
services are urgent user services; some are underpinning requirements 
needed to assure the user services; some are longer term needs. 

There is clearly a strong interaction between the user services and 
the underpinning ones; there is also some between the user services 
themselves. Partly as a result of our own deliberations, and partly 
as a result of our polls of the other working groups, we have 
identified needs in the areas below. 


USER SERVICES 


In most cases these are services which are available in local or 


homogeneous environments. For the proposed collaborations they must 
be available on an intercontinental basis between heterogeneous 
systems. 
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6.1 Electronic Mail 


The current email services between the US and Europe suffer from gaps 
in connectivity, lack of reliability and poor responsiveness. These 
problems stem, in part, from the multiplicity of protocols used (and 
requiring translation) and in part from an inadequate operations and 
maintenance infrastructure. There are few user and directory support 
services available; access to, and use of, email service varies 
dramatically. However, some initial cooperative work has started 
already between RARE Working Group 1 and participants in the Internet 
Engineering Task Force in the area of email. 


6.1.1 One Year Targets 


(i) Provide management structure to support user assistance and 
reliable operation of email relays; 


(ii) Achieve routine expectation of proper and timely (less than 
1 hour campus-campus) delivery. 


6.1.2 Three Year Targets 
(i) Provide global, email directory services; 
(ii) Develop and deploy a return/receipt facility; 
(iii) Provide support for privacy and authenticity. 
6.1.3 Recommended Actions 
(i) Initiate an intercontinental email operations forum involving 
email service providers in the US and Europe to define and 


implement operational procedures leading to high reliability; 


(ii) Task the email operations forum to develop functional and 
performance specifications for email gateways (relays); 


(iii) Organize an international email user support group; 


(iv) Organize a collaborative working group to analyse email 
interoperability problems (X.400, UUCP, SMTP, EARN, EUROKOM, 
BITNET) and make recommendations for specific developments to 
improve interoperability. 


Included in the terms of reference should be requirements for 
cryptographic support for privacy, authenticity and integrity of 
email. This work could include specific collaboration on X.400 and 
SMTP privacy enhancement methods. (Note there are serious 
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international obstacles to achieving progress in areas involving 
cryptographic technology.) 


See Directory Services section for further possible actions. 


6.2 Compound Document Electronic Mail 


While proprietary solutions for compound documents (text, font 
support, geometric graphics, bit-map graphic, spread-sheets, voice 
annotation, etc.) exist, these are limited to products of single 
manufacturers. While international standards for compound documents 
exist, these are still evolving, and few real commercial products 
based on the standards exist. Nevertheless, both proprietary and 
open systems compound document mail services could be made available 
reasonably quickly. 


6.2.1 One Year Targets 


(i) Support proprietary compound document email for groups 
interested in using specific conforming products; 


(ii) Provide experimental services to groups with open systems 
offerings using several products. Support interoperation 
for multi-font text, bit-mapped and geometric graphics. The 
software could be provided from that arising from the 
combination of a previous NSF and an ESPRIT proposal. 


6.2.2 Three Year Targets 


Provide support for open system compound document email and document 
exchange including the following facilities: spreadsheets; integrity, 
authentication and non-repudiation of origin of document parts; 
confidentiality of document parts. 


6.2.3 Recommended Actions 


Hold a workshop to review the ongoing compound document research and 
development programmes in the two regions. One aim would be to 
recommend services for deployment in the short term. Another would 
be to propose work items in the NSF/DARPA and ESPRIT programmes to 
ensure a timely collaborative programme could start in mid-1991. 


6.3 Directory Services 


White pages services to assist network users to find email addresses, 
computer services and other on-line facilities are, at best, only 
lightly deployed in both the US and Europe. If networked services 
are to become infrastructural in nature, directory services must be 
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widely implemented, deployed and easily accessible. In addition to 
working with international standards such as CCITT X.500, access to 
the installed base of white pages services (such as the US WHOIS 
service and the UK NRS service) is essential. These facilities are 
also needed to support key management for cryptographic services 
required for authenticity, integrity and confidentiality of email and 
other communications. Because there are different legal and 
organizational views of directory service information, it will also 
be critical to address organizational and international differences 
in the sensitivity of such data and its accessibility. 


It is essential that directory service databases be built and 
maintained throughout the US and European research communities. 


6.3.1 One Year Targets 


(i) Get effective access to existing directory services 
(X.500 and others); 


(ii) Put in data for relevant NSF/DARPA and ESPRIT communities. 
6.3.2 Three Year Targets 
(i) Provide tools to support database maintenance; 
(ii) Provide good knowledge-based navigation software; 
(iii) Provide strong authentication facilities; 
(iv) Provide capability-—based access restrictions. 
6.3.3 Recommended Actions 
Initiate a formal collaboration between ongoing US and European 
(e.g., RARE WG3) efforts to implement and maintain the relevant 
directory databases. 
6.4 Interactive Login 
Interactive access to service systems in the US and Europe is, at 
present, only partly feasible. One inhibiting factor is incompatible 
protocol suites in use in the provision of such services. The 
implementation and deployment of common protocols, and the provision 


of protocol translation gateways, are needed to improve this 
situation. 
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6.4.1 One Year Target 


Identify and install the best available interactive login software 
(using staging gateways, if necessary) on all interested sites. 


6.4.2 Three Year Targets 
Improve interactive login performance to include support for: 
(i) "type of service" (quality or grade-of-service) ; 
(ii) support for privacy; 
(iii) support for authentication; 


(iv) support for remote X-windows even through different protocol 
suites. 


6.4.3 Recommended Actions 


(i) Identify for which protocol suites interactive login will be 
supported; 
(ii) Determine mechanisms for good performance in staged facilities 


(i.e., in which it is necessary to login and then open 
manually new connections from the intermediate gateways) ; 


(iii) Develop a cooperative effort on authentication and privacy 
support. 


6.5 File Services 
File transfers are not easily achieved in the multi-protocol 
environment, and long files cannot be transferred reliably. Manual 
movement of files through staged, protocol-translating gateways is 
awkward and often unreliable. Performance of file transfer software 
varies substantially. Improvements in file transfer facilities are 
needed, but there should also be other forms of file service based on 
shared file systems. 


6.5.1 One Year Targets 


Develop or identify and install the best available file transfer 
software (providing staging gateways, if necessary) to support: 


(i) Multi-megabyte file transfers; 


(ii) Translation between distinct file transfer protocols; 
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(iii) High performance and robustness; 


(iv) Use of wide-area file systems, e.g., Andrew; 


(v) Ad hoc sharing of sections of file systems across two machines. 
6.5.2 Three Year Targets 


Develop (or obtain) and deploy file transfer services with: 


(i) support for privacy, authentication and integrity; 
(ii) support for automatic staging through several file transfer 
relays; 


(iii) support for multi-party access of selected portions of file 
systems across multiple machines. 


6.5.3 Recommended Actions 


(i) In conjunction with RARE WG4 and IETF, identify best available 
products for multi-hop (staged) file transfer; 


(ii) Define and carry out comparative performance tests to select 
best available file transfer software, including checkpointing; 


(iii) Define and implement fuller multi-hop, multi-protocol 
facilities with automated staging, security and management 
facilities; 


(iv) Develop access control models, policies and mechanisms to 
support collaborative file access by ad hoc groups. 


6.6 Group Communication Services 


Coordination of collaborative efforts can be substantially enhanced 
through provision of mailing lists, bulletin boards and shared 
databases. Setting up and managing such facilities, however, 
typically requires special knowledge and privileges. Making it 
possible to set up and operate such facilities easily and without 
special privileges would enhance the infrastructure of support for 
collaborative activities between the US and Europe (and within each 
region as well). 


More advanced group communication services such as shared screens 
with voice teleconferencing, distributed publishing through 
electronic libraries, and various forms of teleconferencing, might 
relieve some of the necessity for face-to-face meetings, if 


Cerf, Kirstein, & Randell [Page 14] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


sufficiently reliable and easy to use. The prior use of such 
facilities make subsequent face-to-face meetings much more productive 
also. Of course, time zone differences are a challenge to any real- 
time conferencing schemes, and are often the primary rationale for 
arranging face-to-face conferences which "force" participants to 
enter the same time zone for the duration of the meeting. 


6.6.1 One Year Targets 


(i) Provide administrative support for setting up and maintaining 
email mailing lists, bulletin boards and shared databases; 


(ii) Provide facilities for multi-site interactive blackboards 
including text, graphics, spreadsheets and program access. 


6.6.2 Three Year Targets 


(i) Provide intercontinental services based on more mature "advanced 
groupware" facilities including shared screens and voice 
services; 


(ii) Extend interactive blackboard to include slow scan video, voice, 
animation, and using international standards where feasible. 


6.6.3 Recommended Actions 


(i) Form a support/working group on the use of tools, standards and 
facilities for group communication services; 


(ii) Initiate collaboration on advanced group communications (e.g., 
shared screens, distributed electronic publishing, etc.). 


6.7 Video Conferencing 


Facilities for low bandwidth (under 1 Mb/s) interactive video/voice 
conferencing (e.g., packet-based) are, at present, unavailable for 
support of intercontinental collaboration. Even two-party 
videoconferencing could be beneficial initially. The comments from 
the other seven working groups showed a strong interest in the use of 
videoconferencing, provided the travel to the relevant facilities did 
not exceed two hours. This should impact the eventual deployment 
plans for the facilities. 


Minimum facilities needed for video conferencing include at least 256 
Kb/s across the Atlantic for each concurrent conferencing channel. A 
video codec, two cameras and three monitors are needed at each site 
along with suitable packetizing equipment if a packet-mode system is 
to be deployed. There exists at least one such system in use in the 
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US, developed by DARPA and used regularly for transcontinental 
working group meetings. Another such system is just being 
commissioned (at University College London). 


6.7.1 One Year Target 


Deploy two-party videoconferencing facilities in at least four sites 
on each continent. 


6.7.2 Three Year Target 
Develop and deploy multi-party conferencing capability on a larger 
scale on both continents, to make the facilities accessible more 
widely to the collaborators with less travel penalty. 

6.7.3 Recommended Actions 
(i) Install existing technology at a limited number of sites in 

both regions, in line with the desire to limit travel 
mentioned above; 

(ii) Organize a workshop on packet/ISDN/ATM videoconferencing. 

6.8 Multimedia Computer Supported Group Working 
The NSF has initiated an effort on collaboration technology 
development and experimentation under the rubric: Collaboratory. 
Similar research is in progress under the ESPRIT programme. While 
the subject of the NIWG’s discussions was designated as 
infrastructure support for the other research collaborations, we 
believe it is very appropriate to mount a collaborative programme 
among US and European researchers, which would enhance Collaboratory 
efforts and force both groups to come to grips with problems of 
supporting collaboration techniques across intercontinental 
distances. 

6.8.1 One Year Target 
Harmonise the ESPRIT and NSF Collaboratory research programmes. 


6.8.2 Three Year Target 


Set up a common, transatlantic testbed facility to support 
collaborative research programmes. 


6.8.3 Recommended Actions 


Set up a workshop to study the needs of a collaborative effort to 
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provide intercontinental packet video, multimedia conferencing and 
computer supported collaborative group technology facilities. The 
workshop should propose actions which could be made the basis of a 
future harmonised ESPRIT and DARPA/NSF work programme. 


6.9 Access to Unique Resources 


A number of resources can be labelled unique in the scope of 
ESPRIT/DARPA/NSF or even on a worldwide basis. Their uniqueness may 
derive from their nature (e.g., large test facilities or a focus 
point of knowledge in a discipline) or be such in a transitory phase. 
In the spirit of the future EC/US cooperation, it is clear that there 


should be agreed access to some such resources. This will require: 
(i) Provision of appropriate access and usage information; 
(ii) Physical access for visitors; 


(iii) Continued non-local access. 


The third point has clear networking implication. Appropriate remote 
access to the resources, connectivity to the users and adequate 
access speeds have to be provided, possibly together with access 
control facilities. 


The most demanding cases are those of newly developed products; their 
transitory uniqueness does not allow one to amortise costs over 
substantial periods as would be reasonable for large scale centres 
like NCAR or CERN. 


6.9.1 One Year Target 


(i) Identify appropriate unique transitory resources 
(e.g., Touchstone); 


(ii) Specify the provisions needed to make at least one such 
resource available. 


6.9.2 Three Year Target 


Set up one or more significant transatlantic pilots demonstrating 
remote, secured access. 


6.9.3 Recommended Actions 
Organise a workshop dedicated to analysing the needs and defining the 


steps required to provide pilot access to one or more specific such 
resources. The workshop may need to address networking needs, 
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security provisions, documentation and advisory requirements, 
modification of current access capabilities, and usage policies. 


6.10 Distributed Visualization 


Scientific visualization applications often involve multiple 
resources. These resources can span a complete range of 
sophistication, from simple hardcopy at one end to elaborate 
rendering at the other end. Interactive graphics workstations, 
supercomputers and specialized scientific databases may all be 
involved in a single application. The scientist at a workstation 
should be able to view all of these resources as a single network 
resource, although they may be physically distributed over 
considerable distances. A typical example is a high performance 
graphics workstation, a supercomputer and a network to connect them 
together, all with appropriate software. The workstation may be 
close to the supercomputer or distant from it. 


Currently there are efforts underway at several installations - 
including ones funded by NSF/DARPA and ESPRIT - to develop 
techniques, interfaces and software necessary to create this 
environment. In limited instances it already exists. Better 
coordination of these efforts on both sides of the Atlantic would be 
desirable. Coordinating such efforts across the Atlantic will be 
necessary for effective collaboration in end-user visualization 
applications in a variety of disciplines to take place in the future. 


6.10.1 One Year Targets 


Identify the significant current development efforts in these areas 
and determine which ones to support. Identify the areas requiring 
standards. Minimize duplication of effort and begin to distribute 
the techniques and software. 


6.10.2 Three Year Targets 


Establish mutually agreed upon standards. Demonstrate transatlantic 
distributed visualization applications. 


6.10.3 Recommended Actions 


Establish a working group to further refine and to implement the one 
year and three year targets and to identify additional distributed 
visualization topics that would benefit from coordinated efforts. 
Determine the appropriate mechanisms for supporting such 
collaborations. 
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UNDERLYING SERVICES 


Most of the services described below are required to achieve the 
goals of reliability, availability and transparency of the user 
services. 


6.11 Network Management 


Current network management technology and practice are not adequate 
to support large scale, international research networks. Time-zone 
differences and lack of organizational operational network management 
agreements combine to make international network management a serious 
challenge. To be effective, network management must operate ona 
campus-to-campus basis, since the campuses are the sources and sinks 
of traffic in the system. 


6.11.1 One Year Target 


Put in place an administrative structure to coordinate existing 
facilities manually and to plan technical solutions. 


6.11.2 Three Year Target 


Develop and deploy technology for automating international network 
management. 


6.11.3 Recommended Actions 


(i) Convene an international research network operations, 
planning and management team to develop and apply 
procedural and technical recommendations for international 
network management; 


(ii) Organize a set of international network operations centres 
devoted to configuration management, fault detection, 
isolation and repair of network problems; 


(iii) Form one or more intercontinental Computer Emergency Response 
Teams to coordinate response to attacks against hosts and 
networks and to develop procedures for collecting actionable 
evidence. 


6.12 Multi-protocol Support 
Users depend on a variety of protocols to support their research. 
The international network infrastructure does not uniformly support 


the use of multiple protocols (e.g., DECNET, TCP/IP/ST, OSI) on an 
end-to-end basis. The use of various portions of the international 
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network also may be restricted by policy, and this must be 
accommodated in implementing routing for campus-to-campus protocols. 


Support for campus-to-campus multi-protocol transmission and routing 
is needed at a minimum of 64 Kb/s end-to-end - higher for the support 
of some of the services. Where the end-users have adopted similar 
protocols, the intervening networks should not impede the full 
exploitation of the facilities available in the chosen protocol 
suite. Where different protocol suites are used, high quality 
application-level gateways which can translate among protocols are 
needed also; to the greatest extent possible, these should allow 
people to use their own procedures, even though they are 
communicating with services which use different ones. For some 
services, this will lead to a requirement to upgrade access, and 
possibly even transparent access (including protocol conversion), to 
at least 1.5 Mb/s between individual campuses in the US and Europe. 


6.12.1 One Year Targets 
(i) Support campus-to-campus communication for a subset of 
coexisting protocol suites (at least OSI and TCP/IP) at a 


minimum of 64 Kb/s; 


(ii) Deploy internationally supported versions of existing 
application level (protocol-translating) gateways. 


6.12.2 Three Year Targets 


(i) Improve management and resource allocation for multi-protocol 
routers (e.g., to achieve service guarantees) ; 


(ii) Support campus-to-campus communication at a minimum of 1.5 Mb/s. 
6.12.3 Recommended Actions 


(i) Validate current multi-protocol solutions for intercontinental, 
and indeed campus-to-campus use; 


(ii) Collaborate on research and experimentation with multi-protocol 
routing and resource allocation; 


(iii) Make recommendations, to funders and national research network 


service providers, on technical solutions and standards for 
multi-protocol support. 
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6.13 Client-Server Technology 


Among the more important computer communications techniques emerging 
on a widespread basis during the last decade is the client-server 
model of interprocess communication. This notion was actually 
developed during the earliest stages of packet network exploration 
and dramatically enhanced with the invention of local area networks 
(such as Ethernet) which could support very high speed, low delay 
inter-computer exchanges. Applications of this concept range from 
remote procedure calls to remote file access and support for remote, 
bit-mapped graphics. 


At present, these techniques work best in a high bandwidth, low delay 
environment; they are generally not well-supported in wide-area, 
intercontinental networks. Collaborative efforts between the US and 
Europe could be enhanced substantially by support for client-server 
services on an intercontinental basis. Such facilities would permit 
collaborative use of distributed filing systems, X-windows 
applications and other distributed computing applications. High 
capacity, low-delay channels will be needed on an intercontinental 
basis to support serious use of this technology. In addition, 
agreement must be reached on which protocols should be used to 
support this technology. 


6.13.1 One Year Targets 


(i) Provide limited bandwidth intercontinental X-Windows support 
for graphical user interfaces; 


(ii) Achieve agreements on intercontinental Remote Procedure Call 
and Distributed File System protocols; 


(iii) Validate support of X-Windows under OSI and through protocol 
translating gateways. 


6.13.2 Three Year Targets 


(i) Achieve selective support for intercontinental remote 
visualization; 


(ii) Achieve support for intercontinental RPC and Distributed File 
Systems. 


6.13.3 Recommended Actions 


(i) Convene workshops to achieve agreements on intercontinental 
Remote Procedure Call and Distributed File System protocols; 


Cerf, Kirstein, & Randell [Page 21] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


(ii) Form working group on support for X-Windows in OSI and to 
validate performance through TCP/TPn protocol translating 
gateways; 


(iii) Initiate collaboration on implementation and test of 
intercontinental RPC and distributed file systems. 


Section 6.14 Archival Storage for Distributed Computing Environments 
There are several major issues that must be addressed by distributed 


computing environments (DCEs) containing supercomputers. Resolution 
of these issues is likely to evolve over the next five to ten years. 


One such issue is archival storage and bitfile management for the 
complete environment. Several problems have to be resolved to 
appropriately handle this situation. The first problem is the 
global-naming of bitfiles that are being moved through the DCE 
to/from the archive. Second, the file system hierarchy must be 
defined. Third, there is the question of how the DCE knows the file 
system hierarchy for which it is responsible, and the location of the 
boundary through which the network and the archival system operate. 
Lastly, there is the question how the file system hierarchy is 
divided across a DCE and within a supercomputer. 


A second issue in the DCE is the need for all nodes obtaining or 
storing data to know the storage media differences. For future 
systems, this requirement manifests itself both at the distributed 
nodes and at the supercomputer because of the differences in the 
physical media structure. 


The third issue is the delineation of the bitfile attributes. This 
relates to how the data must be maintained as it migrates through the 
hierarchy, as well as through the DCE. The bitfile carries 
attributes based upon its location in the hierarchy, or in the DCE, 
that may be different from those needed at the supercomputer level. 
Many of these attributes are related to the data content and where it 
resides in time within the DCE. Section 6.15 discusses some of the 
possible meta-data representation methodologies that may be used but 
are not yet standardized. 


Another issue is the determination and implementation of the site 
policy that is to dictate data migration and allocation inside the 
DCE archival storage system. 


Several working committees are attacking the various problems 
delineated above, and are trying to confront the difficulties in 
these environments. This work is progressing mostly in the United 
States. The IEEE Computer Society Technical Committee on Mass 
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Storage Systems is in the process of developing a Computer Society 
draft standard on data storage systems. The current working draft 
provides a consistent terminology and an object-oriented design for 
defining storage subsystem components, whether they are being built 
around a single system or in a DCE. Other groups in the computing 
community are currently dealing with the problems of data migration 
within a distributed environment. This distributed environment may 
or may not include a supercomputer, but it almost always includes a 
high-volume storage system of some sort delineated as a "mass storage 
system." This subject was not discussed long enough at the meeting to 
deduce one year or three year targets - indeed these may well be set 
by the relevant National working groups. 


6.14.1 Recommended Actions 
Convene an international workshop whose goals are: 
1. An understanding of the contents of the data storage reference 
model that is nearly ready to be declared an official standard 


guide; 


2. To continue discussion of the various system issues that have 
to be developed as a result of this model; 


3. To arrive at solutions to be proposed by vendors and users for 
implementations of Data Systems Storage Solutions which are 
modular, interconnectable, and standard. 


6.15 Data Representation and Exchange 


The problem of data exchange between different computer architectures 
and operating systems has been existent since the deployment of the 
early computers. This problem has been exacerbated by the acceptance 
of the client-server paradigm as the provider of distributed 
services. Distributed computer services require immediate data 
exchange. In the past, data was exchanged on some medium, such as 
tape, and could be examined at leisure. Ad hoc data conversion 
routines were created to process the data, and were often embedded in 
the programs using the data. Data exchange in the client-server 
paradigm does not permit this leisurely data examination. Both the 
client and the server must be able to "call" software that is 
guaranteed to convert the exchanged data "on the spot." This 
guarantee also implies a standard format rather than the ability to 
convert all formats because it would be impossible to maintain 
multiple architecture conversion software and, of course, the size of 
such conversion software would be enormous. 


The issue of data exchange has been addressed resulting in many data 
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exchange software packages. A few of the currently more popular 
packages are XDR, HDF, NetCDF, PostScript and CCSDS. Each of these 
packages addresses a specific type of data. Some address bitmap 
data; one addresses the general encoding of "display" information. 
Some of these packages address various numerical representations in 
computers. It is unclear whether any existing package could or 
should be extended to solve all data exchange problems. However, a 
more realistic approach would be a collection of data exchange 
packages formed as the "standard." 


This item was discussed only briefly at the meeting, so that no one 
year or three year targets were specified. 


6.15.1 Recommended Actions 


It is proposed that an international working group be established to 
recommend a standard collection of software encompassing a variety of 
data representations. This working group should address the issue of 
embedding identification of the data representations in the data 
stream to allow for later extensions. The working group would meet 
initially to establish a work-scope and to assign the members tasks. 
The group would schedule subsequent meetings (probably annually) to 
finalise the current data exchange standard recommendation, and to 
define new work scopes. The working group would also make their 
recommendation known to other standards bodies such as X/OPEN, UI, 
OSF, X Consortium, NIST, IEEE, ACM, etc. 


6.16 Transatlantic Links and Continental Distribution 


At present, there is inadequate transatlantic capacity to support 
research collaborations involving significant amounts of computer- 
mediated communication. There is also considerable room for 
improvement in the distribution of capacity and enhancement of 
reliability of network service in Europe. Moreover, the point was 
made strongly that collaboration would be very difficult unless the 
infrastructure on the two sides was broadly comparable - even if the 
transatlantic capacity was per force lower. Moreover, it was sharply 
emphasised that there was a large requirement for transatlantic data 
flow in other fields - e.g., Space Science, Atmospheric Science and 
High Energy Physics. In the US these needs are being aggregated in 
the National Research and Engineering Network; such aggregation is 
required also in Europe and on a transatlantic basis. 


6.16.1 One Year Targets 
(i) Install 2 Mb/s multi-protocol distribution facilities in Europe; 


(ii) Install 1.5 Mb/s (or higher) transatlantic capacity. 
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6.16.2 Three Year Targets 


(i) Install 2 additional 1.5 Mb/s (or higher) transatlantic links 
by 1993; 


(ii) Determine feasibility of sharing much higher bandwidth 
intercontinental links (e.g., in the 51 Mb/s STS-1 range). 


6.16.3 Recommended Actions 


(i) Use existing joint US/European coordination mechanisms 
(e.g., CCIRN) for planning of higher speed, transatlantic 
links; 

(ii) Convene a special CEC/DARPA/NSF task force to consider much 


higher speed transatlantic capacity sharing options; 


(iii) Ensure that there is an infrastructure in Europe, paralleling 
the US one, providing the majority of relevant campuses access 
at speeds approaching 1.5 Mb/s; 


(iv) Encourage European user groups with high data transmission 
requirements to aggregate their data transmission facilities. 
Attempt to integrate European application projects (like the 
RACE Applications Pilots) to assist in providing an appropriate 
European distribution network with 10 - 500 Mb/s access to 
appropriate campuses. 


7. LONGER TERM INITIATIVES 
Although these were not discussed in any detail, for lack of time, 
the following areas emerged as of interest for longer term 


collaborative work: 


(i) Electronic Library Services (includes an important 
intellectual property rights component); 


(ii) Multi-media Computer Supported Collaborative Work; 
(iii) Portable Computing/Communications Environments; 


(iv) Distributed Computing using heterogeneous machines and unique 


facilities; 

(v) Compatible approaches to computer networks with Gb/s access 
speeds, and appropriate systems switching, transmission and 
protocols. 
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It was felt that some collaborative research in these areas would 
have immense medium term benefits to the other communities - and 
would integrate well with the ongoing research programmes on both 
sides of the Atlantic. 


8. OBSTACLES 


The largest single obstacle to the provision of the facilities 
outlined in this report are that development of the necessary 
facilities do not have priority to most funding agencies. This is 
exemplified by the role of our workshops in this series. Not only 
network provision, but also development of appropriate infrastructure 
application software and testbed activity, are essential. 


There are a number of problem areas which could benefit from official 
attention from CEC and US research funding agencies. For example, 
there are a number of open and proprietary protocol suites which are 
candidates for use in US/European collaborative research. However, 
there is lack of political agreement as to how to deal with these 
various suites. It would be politically valuable if the CEC and US 
research agencies could issue a communique outlining common agreement 
on treatment of multiple protocols (e.g., expressing serious interest 
in supporting campus-to-campus communication using multiple 
protocols). Within the OSI protocol suite, there are differences as 
to which features ought to make up the standard profile for use by 
government-sponsored groups. Handling of connection-oriented and 
connectionless protocol elements within the suite is the subject of 
continued debate. Agreement to support at least TCP/IP and the 
connectionless network protocol in the OSI suite on an 
intercontinental basis would be beneficial to both parties; many CEC 
members would like connection-oriented network protocols to be 
supported also. 


European international tariffs are relatively high. This has 
inhibited the implementation of private networks and impeded progress 
on collaborative work between the US and Europe. A CEC initiative to 
come to grips with this problem could be quite helpful. 


There are a diversity of intra-European networking organizations 


which have technical, operational and policy interests. Planning for 
intercontinental networking infrastructure is sometimes confused by 
the variety of interested parties. Effort towards further 


coordination and rationalization of intra-European networking 
activities could make intercontinental planning somewhat easier. 


There is a strong interest in the use of cryptographic methods to 


provide privacy, authenticity and integrity assurance for various 
forms of intercontinental communication and at various levels in the 
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protocol hierarchies. Although there appears to be substantial 
technical activity in this area, progress is now impeded by national 
restrictions on the export of software which utilizes cryptographic 
methods. National use policies vary and the ability to apply these 
valuable and needed techniques is uncertain. 


Some national privacy and data protection laws prohibit the creation 
of directories containing personal information (e.g., email and 
postal addresses) and other laws limit what kinds of information (and 
in what form) can be transported across national borders. 


Handling of cryptographic exchanges, import/export of supporting 
software and exchanges of keying information are all potentially 
subject to national restrictions and constraints. The government 
agencies interested in promoting international collaboration may need 
to seek alternative international formulations of permitted practice 
to permit the required technical support. 


Finally, several organizations in the US and Europe have pointed out 
that the provision of networking infrastructure requires stable 
funding over significant periods of time. Stability for 
infrastructure support has been shaky in the US and in Europe and 
this presents an obstacle to achieving widespread and reliable 
network services to aid collaborative efforts. 


9. CONCLUDING REMARKS 


The set of proposals contained in this report provide a realistic, 
staged approach to ameliorating the grave problems caused by the 
disparities with respect to bandwidth provision, user services and 
network protocol issues that impede widespread and close 
transatlantic collaboration at present between the ESPRIT and 
DARPA/NSF research workers. Their implementation will require a 
considerable degree of commitment to resolve present administrative 
difficulties, but the financial resources needed would, we estimate, 
be relatively modest and fully commensurate with the benefits to be 
gained. 


Cerf, Kirstein, & Randell [Page 27] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


APPENDIX A NIWG PARTICIPANTS 
(1) and (2) indicate the Brussels and Washington meetings respectively 
Co-chairmen: 


Ira Richer (1), (2) Rolf Speth (1) Tom Weber (2) Rosalie Zobel (1), (2) 


DARPA CEC NSF CEC 
Rapporteurs: 

Vint Cerf (1) Peter Kirstein (1), (2) Mike Levine (2) 
CNRI UCL PSC 


Other Participants: 


Franco Bigi (1) Adriano Endrizzi (1), (2) Juan Riera(1) 
William Bostwick (1) David Farber (1) Jack Thorpe (1) 

Bill Buzbee (2) Steve Goldstein (1) Jose Torcato (1), (2) 
Mike Eyre (2) Sid Karin (2) Klaus Ullmann (1) 
Robert Cooper (1) Barry Leiner (1) Paul Wilson (2) 

Steve Crocker (2) Jean-Pierre Peltier (2) Bill Wulf (2) 

Karel De Vriendt (1) Brian Randell (1), (2) 


APPENDIX B - NETWORKING AND INFRASTRUCTURE WORKING GROUP: TELEPHONE, 
EMATL AND FAX NUMBERS 


Franci Bigi (1) 

CEC 

Rue de la Loi 2000 

B-1049 

Brussels 

BELGIUM 
Tel: +32 2 236 3493 
Fax: +32 2 235 6937 


William Bostwick (1) 

US Dept of Energy 
Tel: +1 703 276 3533 
Fax: +1 703 276 2536 
Email: bostwick@darpa.mil 


Cerf, Kirstein, & Randell [Page 28] 


RFC 1210 


Bill Buzbee (2) 
National Center for Atmospheric Research 
P.O. Box 3000 
Boulder, CO 80307 
USA 
Tel +1 303 497 120? 
Fax +1 303 497 1137 
Email buzbee@bierstadt.ucar.edu 


Vinton Cerf (1) 
Corporation for National Research Initiatives 
1895 Preston White Drive, Suite 100 
Reston, VA 22091 
USA 
Tel: +1 703 620 8990 
Fax: +1 703 620 0913 
Email: vcerf@nri.reston.va.us 


Robert Cooper (1) 
Rutherford and Appleton Laboratories 
Didcot, Oxon, 0x11 0QX 
UK 
Tel: +44 23544 5459 
Fax: +44 23544 5808 
Email: R.Cooper@Rutherford.AC.UK 


Steve Crocker (2) 
Trusted Information Systems 
3060 Washington Road 
Glenwood, MD 21738 
USA 

Tel: +1 301 854 6889 

Fax: +1 301 854 5363 
Email: crocker@tis.com 


Adriano Endrizzi (1), (2) 
JRC 
21020 ISPRA 
ITALY 
Tel: +39 332 789213 
Fax: +39 332 789098 
Email: a_endrizzi@cen.jrc.it 


Cerf, Kirstein, & Randell 


Network and Infrastructure User Requirements 


(CNRI) 


March 1991 


[Page 29] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


Michael Eyre (2) 
Architecture Projects Management Ltd (ANSA) 
Poseidon Ho 
Castle Park 
Cambridge 
CB30RD 
UK 
Tel: +44 223 323010 
Fax: +44 223 359779 
Email: dme@ansa.co.uk 


David Farber (1) 
University of Pennsylvania 
200 South 33rd Street 
Philadelphia, PA 19104-6389 
USA 

Tel: +1 215 898 9508 

Fax: +1 215 274 8293 
Email: farber@cis.upenn.edu 


Steve Goldstein (1) 
NSF 
18th & G Street, NW 
Washington, DC 20550 
USA 
Tel: +1 202 357 9717 
Fax: +1 202 357 0320 
Email: sgoldstein@note.nsf.gov 


Sid Karin (2) 
San Diego Supercomputer Center 
University of California at San Diego 
San Diego, CA 92186-9784 
USA 

Tel: +1 619 534 5075 

Fax: +1 619 534 5113 
Email: Karin@sdsc.edu 


Peter Kirstein (1) (2) 
University College London 
Gower Street 
London 
WCIE GBT 
UK 

Tel: +44 71 380 7286 

Fax: +44 71 387 1397 
Email: kirstein@cs.ucl.ac.uk 


Cerf, Kirstein, & Randell [Page 30] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


Barry Leiner (1) 
Research Institute for Advanced Computer Science (RIACS) 
USA 
Tel: +1 415 694 6362 
Fax: +1 415 962 7772 
Email: leiner@riacs.edu 


Michael Levine (2) 
Pittsburgh Supercomputing Center 
Carnegie Mellon University 
Pittsburgh, PA 15213 USA 

Tel: +1 412 268 4960 

Fax: +1 412 268 5832 
Email: levine @a.psc.edu 


Jean-Pierre Peltier (2) 
ONERA 
Chatillon CEDEX 
BP 72 
92322 
FRANCE 
Tel: +33 1 4657 1160 
Fax: +33 1 4746 9025 
Email: Peltier@Froner81.bitnet 


Brian Randell (1), (2) 
Computing Laboratory 
University of Newcastle upon Tyne 
NE1 7RU 
UK 
Tel: +44 91 222 7923 
Fax: +44 91 222 8232 
Email: Brian.Randell@newcastle.ac.uk 


Ira Richer (1) (2) 
Defense Advanced Research Projects Agency (DARPA) 
1400 Wilson Bld 
Arlington, VA 22209 
USA 
USA 
Tel: +1 703 614 5800 
Fax: +1 703 614 5004 
Email: richer@darpa.mil 


Cerf, Kirstein, & Randell [Page 31] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


Juan Riera (1) 
University of Madrid 
ETSI 
Ciudad Universitaria 
E-28040 
Madrid 
ESPAGNA 
Tel: +34 1 449 5762 
Fax: +34 1 243 2077 
Email: jriera@dit.upm.es 


Rolf Speth (1) 
CEC 
Rue de la Loi 2000 
B-1049 
Brussels 
BELGIUM 
Tel: +32 2 236 0416 
Fax: +32 2 235 0655 
Email: Rolf_speth@eurokom.ie 


Jack Thorpe (1) 
Defense Advanced Research Projects Agency - Europe (DARPA-E) 
GERMANY 
Tel: +49 711 715 5418 
Fax: +49 711 715 5448 
Email: thorpe@darpa.mil 


Jose Torcato (1), (2) 
CEC, TR 61 0/10 
Rue de la Loi 2000 
B-1049 
Brussels 
BELGIUM 
Tel: +32 2 236 3537 
Fax: +32 2 235 6937 
Email: -- 


Klaus Ullmann (1) 
Deutsche Forschungsnetz 
Pariserstr. 44 
D-1000 Berlin 15 
GERMANY 

Tel: +49 30 8842 9920 

Fax: +49 30 8842 9970 
Email: ullmann@zpl.dfn.dbp.de 


Cerf, Kirstein, & Randell [Page 32] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


Karel De Vriendt (1) 
CEC 
Rue de la Loi 2000 
B-1049 
Brussels 
BELGIUM 

Peles 

Fax: +32 3 235 0655 
Email: k_d_v@eurokom.ie 


Thomas A. Weber (2) 
NSF 
18th & G Street, NW 
Washington, DC 20550 
USA 

Tel: +1 202 357 7558 

Fax: +1 202 357 0320 
Email: tweber@note.nsf.gov 


Paul Wilson 
Computer Sciences Company Ltd. 
Computer Sciences House, Brunel Way 
Slough, Berkshire SL1 1XL 
UK 

Tel: 0753 73232 

Fax: 0753 516178 
Email: wilson@cs.nott.ac.uk 


Bill Wulf (2) 
University of Virginia 
Charlottesville, VA 22903-2442 
USA 

Tel: +1 804 982 2223 

Fax: +1 804 982 2214 
Email: wulf@virginia.edu 


Rosalie Zobel (1) (2) 

CEC 

Rue de la Loi 2000 

B-1049 

Brussels 

BELGIUM 
Tel: +32 2 236 0324 
Fax: +32 2 236 3031 

Email: R_Zobel@eurokom.ie 


Cerf, Kirstein, & Randell [Page 33] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


APPENDIX C GLOSSARY 


There is no attempt to provide a comprehensive glossary. However, 
some of the participants were unfamiliar with the terms used on the 
other side of the Atlantic, so some of the more parochial technical 
terms are defined below. 


CCITT - The international body responsible for recommendations 
to the National communications authorities. 


CLNP - Connectionless Network Protocol. A specific ISO/OSI 
protocol analgous to the IP mentioned below. 


CONS - Connection-oriented service. Another specific ISO/OSI 
protocol more aligned to the X.25 protocol mentioned below. 


Compound Document - Documents containing different content types 
including some of the following: text (possibly with various 
fonts), geometric graphics, bit-map graphics, spreadsheets, 
tables, animation, voice annotation. 


TAB - The Internet Activities Board. This is the body which 
guides the evolution of the TCP/IP protocol suite and the 
general Internet architecture. The Internet Engineering Task 
Force and Internet Research Task Force are subsidiary 
activities of the IAB. 


IETF - The Internet Engineering Task Force. This is a working 
group responsible for the specification, development and 
discussion of the operation of facilities in the Internet 
research networks, which are the basis of US research network 
services - but also have European counterparts and 
participation. 


Internet - The concatenations of packet-switched networks which 
comprise the research networks used by most of the contractors 
of the NSF and DARPA (amonsgst other US groups). The Internet 
also extends to other countries including some in Europe. 


IP - The Internet Protocol. This is the lowest level protocol which 
is the basis of the current Internet. 


ISO - The International Standards Organisation. The international 
organisation responsible for the standardisation of a broad 


range of facilities including network ones. 


IXI - The international packet switched network which has been 
installed by the European communication authorities as part 


Cerf, Kirstein, & Randell [Page 34] 


RFC 1210 Network and Infrastructure User Requirements March 1991 


of a European project to provide an international backbone 
network linking in the West European National research (and 
public) networks. 

OSI - Open Systems Interconnection. An evolving set of ISO 
standards which should allow services on different host 
computers networks to inter-operate. 


RARE - The international committee comprising representatives of 
European National and international research networks. 


TCP/IP - The transport protocols currently used on the Internet. 


X.25 - The Network Access protocols specified by CCITT/OSI as 
standard. 


X.400 - The set of protocols for message services specified by 
CCITT/ISO. 


X.500 - The set of protocols for directory services specified by 
CCITT/ISO. 


Security Considerations 

Security issues are discussed in Sections 6.5, 6.9, and 6.11. 
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